Conversation
The functions are available in each supported version of OpenSSL and LibreSSL, though deprecated in OpenSSL 3.0.
The functions are suggested in OpenSSL 3.0, though available only in that version.
The function was removed in LibreSSL 3.9.
|
Thanks for working on this! I wonder if we can get away with just implementing it with Having said that, I wonder if we want to further make the Perhaps we can implement an algorithm-agnostic What do you think? |
| VALUE cCMAC; | ||
| VALUE eCMACError; |
There was a problem hiding this comment.
Thanks. I thought they could be, but I wasn't sure.
|
|
||
| /* | ||
| * call-seq: | ||
| * CMAC.new(key, cipher = "AES-128-CBC") -> new_cmac |
There was a problem hiding this comment.
IMO we should make cipher a mandatory parameter without a default value.
There was a problem hiding this comment.
I read your comment on #796, and now I agree we should.
|
That will be the best solution if we can stop supporting EOL versions of OpenSSL and all versions of LibreSSL, at least about new features. We are also supporting LibreSSL, and I think it has never had I thought about almost the same approach when I started working on this issue, but I didn't know if we could soon stop supporting live versions or add features that wouldn't work in some environments. That is why I made that hybrid code. I will try to implement In that case, we should add those subclasses under |
|
We also have a choice to define When the version number it will be implemented is unknown, we can check it at compile time in
That sounds reasonable to me. We can't break |
|
#891 is a follow-up to this pull request. |
Implements #802 by adding the
OpenSSL::CMACclass.The class has a similar set of methods to
OpenSSL::HMACexcept thatmacs and that#reset.The class uses different sets of OpenSSL functions depending on the version that the class is compiled against.